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Claims 1-14 and 16-20 are pending in this application. Claims 1-14 and 16-20 are 
rejected. In accordance with the foregoing, claims 1, 2, 12 and 14 are amended and new claim 
21 is added. The rejections are respectfully traversed. 
CLAIM REJECTIONS - 35 U.S.C. § 102 

Claims 1-5, and 7-9 are rejected under 35 U.S.C. § 102(b) as being anticipated by 
Dinallo, US patent no. 5,727,212. 

Claims 14 and 16-20 are rejected under 35 U.S.C. § 102(e) as being anticipated by 
Edmunds, US Pub no. 2003/0231329. 

Claims 1-5 and 7-9 Define over the Cited Art: 

Dinallo fails to disclose, either expressly or inherently, each and every feature of the 
claimed embodiments. Consider claim 1, which recites in part: 
upon receipt of a request for a feature: 

identifying, by the interface, a peripheral device capable of performing 
the specific feature corresponding to the feature requested 

Dinallo fails to disclose, either expressly or inherently, identifying, by the interface, a peripheral 

device capable of performing a specific feature corresponding to the feature requested and 

executing a native driver of the identified peripheral device. The Advisory Action relies upon 

Column 5, lines 30-60 of Dinallo, asserting: "DDInterface identifies the device when it receives 

data buffer from 00 subsystem and calls DDTransport to start the device." Accordingly, it 

appears that the Examiner is relying upon step 512 to disclose the claimed "identifying, by the 

interface, a peripheral device capable of performing a specific feature corresponding to the 

feature requested." However, as discussed in the response filed on December 8, 2008, and as 

seen in Fig. 5 below, the DDInterface establishes a connection with the device in step 508 after 

the OO subsystem sets the data type in step 506. 
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Accordingly, the DDInterface of Dinallo establishes a connection with the device in step 508, 
prior to step 512, and, accordingly step 512 cannot disclose "identifying, by the interface, a 
peripheral device capable of performing a specific feature corresponding to the feature 
requested," as asserted by the Examiner. Furthermore; the 00 subsystem issues a command 
(i.e. play) in step 510. Accordingly Dinallo fails to disclose, either expressly or inherently, 
"upon receipt of a request for a feature: identifying, by the interface, a peripheral device 
capable of performing the specific feature corresponding to the feature requested," because the 
DDInterface is in communication with the peripheral in step 508, before the 00 Subsystem 
issues the command. 

The Office Action, at pages 2-3, relies upon the DDInterface to disclose the claimed 
"interface." However, as seen above, the 00 subsystem sets the data type and attributes in 
step 506 before device driver communication is established in step 508. Accordingly, the 00 
subsytem indicates which device to use. In contrast, claim 1 recites "identifying, by the 
interface, a peripheral device capable of performing the specific feature corresponding to the 
feature requested." One benefit of the claimed embodiment is, for example, that an application 
based upon the claimed interface and requesting a feature can be ported to different computers 
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and used with different peripheral devices without modification since the interface, and not the 
application, identifies a peripheral device capable of performing the specific feature 
corresponding to the feature requested. 

Furthermore, claim 1 is amended to incorporate features from dependent claims 2 and 
3, and recites: 

providing a plurality of parameters to define specific features of the 

peripheral devices, and, 

upon receipt of a request for a feature: 

identifying, by the interface, a peripheral device capable of performing 
the specific feature corresponding to the feature requested, 
determining, by the interface, from the request the specific 
features of the identified peripheral device, 
calling, by the interface, the generic routines as a function of the feature 
with the parameters of the identified peripheral device, 

The Office Action, in rejecting claims 2 and 3, relies upon column 3, lines 35-50 of 

Dinallo, which recites, in part: 

A representative hardware environment is depicted in FIG. 1, which illustrates 
a typical hardware configuration of a workstation in accordance with 
the subject invention having a central processing unit 10, such as a 
conventional microprocessor, and a number of other units 
interconnected via a system bus 12. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an 
I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus 

Accordingly, column 3, lines 35-50 of Dinallo merely discusses the components of a computer. 
Applicants respectfully submit that Dinallo's discussion of a computer fails to disclose the 
claimed "providing a plurality of parameters to define specific features of the 
peripheral devices ... determining, by the interface, from the request the specific 
features of the identified peripheral device, calling, by the interface, the generic routines 
as a function of the feature with the parameters of the identified peripheral device. " 

For the foregoing reasons, withdrawal of the rejection of claim 1 is respectfully 
requested. Claims 2-5 and 7-9 refer to independent claim 1, and therefore patentably 
distinguish over the cited art. 

Claims 14 and 16-20 Define over the Cited Art: 

Edmunds fails to disclose, either expressly or inherently, each and every feature of the 
claimed embodiments. Consider claim 14, which recites in part: 
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a mobile computer configured to provide an interface used by an application to 
access the at least one peripheral device, to use the interface to call a plurality 
of generic routines as a function of a request for a feature, the generic 
routines to cause the native driver, installed on the mobile computer, to 
execute and control the peripheral device and perform a specific 
feature corresponding to the feature requested, the interface being 
independent of device-specific features of the at least one peripheral 
device. 

The Office Action, asserts the "generic driver interface" of Edmonds discloses the 
claimed "interface/' citing paragraphs [0007-0011] of Edmonds. However, Applicants 
respectfully submit that the generic driver interface of Edmonds cannot disclose, either 
expressly or inherently, the claimed "interface ... to call a plurality of generic routines ... the 
generic routines to cause the native driver ... to execute and control the peripheral 
device" as recited in claim 1, because Edmonds generic driver interface uses a generic driver 
to generate print jobs solely on USB printers. (See, Edmonds at paragraph 23, lines 1-6). That 
is, Edmonds' generic driver interface does not use the drivers native to the peripheral device. 

The Office Action, asserts that Edmonds at paragraph [0007] discloses the claimed "as a 
function of a request for a feature, the generic routines to cause the native driver." However, 
paragraph [0007] discusses a Beacon printer, which Edmonds describes as a network printer 
interface, not a USB printer interface. The generic driver interface of Edmonds could not field 
requests to the beacon printer, because the beacon printer, not being connected to a USB port, 
would not respond to generic USB printer command on a USB port. 

Furthermore, Edmonds' beacon interface is located at the beacon printer itself. See, for 
example, paragraph [0018] of Edmonds which discusses that the user must physically walk to 
the desired beacon printer and select the printer through some interface resident on the printer. 
Accordingly, Applicants respectfully submit that Edmonds' beacon printer interface fails to 
disclose the claimed "interface ... to call a plurality of generic routines ... the generic routines to 
cause the native driver ... to execute and control the peripheral device," because the beacon 
interface only allows access to the single device which the user has chosen to walk to. 

Further still, Edmonds beacon driver "must be capable of translating a print job from an 
application into the appropriate page description language (PDL) for any supported 
printer" {See, Edmonds at paragraph 15, lines 8-10). Accordingly, Applicants respectfully 
submit that Edmonds beacon interface fails to disclose, either expressly or implicitly, the 
claimed "to use the interface to call a plurality of generic routines as a function of a 
request for a feature," because the beacon interface uses a PDL specific to the selected 
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printer. That is, there is no evidence that Edmonds beacon printer interface calls generic 
routines, instead the beacon driver must call specific routines to translate a print job into the 
appropriate PDL. 

Furthermore, Applicants respectfully submit that neither the beacon printer interface nor 
the generic USB printer interface of Edmonds disclose the claimed "the interface being 
independent of device-specific features of the at least one peripheral device," because the 
beacon printer interface and the generic USB printer interface are both tied to the specific 
features of a printer. Furthermore, the Office Action fails to cite any art against this feature of 
the claimed embodiment. Accordingly, Applicants respectfully request withdrawal of the finality 
of the outstanding Office Action and issuance of a new non-final Office Action, if necessary, 
addressing each and every feature of the claimed embodiments. 

Accordingly, Edmonds' fails to disclose, either expressly or inherently, the claimed 
"interface ... to call a plurality of generic routines ... the generic routines to cause the native 
driver ... to execute and control the peripheral device driver ... the interface being independent 
of device-specific features of the at least one peripheral device," because Edmonds' generic USB 
printer driver interface uses a generic USB printer driver, not the driver native to the peripheral 
device and Edmonds' beacon printer driver interface only allows access to a single printer and 
does not call generic routines. 

For the foregoing, Applicants respectfully request withdrawal of the rejection to claim 
14. Dependent claims 16-20 refer to independent claims 14 and, therefore, are allowable over 
this art. 

CLAIM REJECTIONS - 35 U.S.C. § 103 

Claims 6, 11, 12, and 13 are rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Dinallo, US patent no. 5,727,212 in view of Edmonds, US pub. no. 2003/0231329. 

Claim 10 is rejected under 35 U.S.C. § 103(a) as being unpatentable over Dinallo, US 
patent no. 5,727,212 in view of Dorris, US patent no. 5,867,710. 

Dinallo and Edmonds, even when considered in combination, fail to disclose, either 
expressly or implicitly, each and every feature of the claimed embodiments. 

The Advisory Action relies upon Edmunds' discussion of a beacon printer to disclose the 
features of the claimed embodiments. As discussed above, Edmonds' beacon interface is 
located at the beacon printer itself and the user selects which printer to use. See, for example, 
paragraph [0018] of Edmonds which discusses that the user must physically walk to the desired 
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beacon printer and select the printer through some interface resident on the printer. However, 
there is no evidence that Edmonds' beacon interface instantiates a connection class to create an 
object specific to the requested peripheral device, uses the instantiated object to cause a native 
driver of the requested peripheral device to execute, and connects, through the native driver, 
the computer to the requested peripheral device, because Edmunds merely discuses that after 
the user selects a printer, "the user's print job is directed to that printer." {See, Edmunds at 
paragraph [0009], lines 10-13). 

Furthermore, Dinallo fails to disclose the claimed "connecting, through the native 
driver, the computer to the requested peripheral device." Dinallo discusses using a 
DDTransport class and a DDInterface to connect device drivers to an object orientated 
subsystem because the device drivers discussed in Dinallo were incapable of connecting to the 
object orientated subsystem without rewriting the computers operating system and its device 
drivers to the standards of object orientated programming. (See, for example, Dinallo at FIGS. 
2 and 6 and at column 1, lines 39-41 and column 5, lines 3-9). 

Accordingly, Applicants respectfully submit that a prima fade case of obviousness cannot 
be based upon Dinallo and Edmunds, because there is no evidence that one of ordinary skill in 
the art would combine Edmunds' beacon printer interface with Dinallo's object orientated 
subsystem/device driver interface and modify the combination to include "instantiating the 
connection class to create an object specific to the requested peripheral device, using the 
instantiated object to cause a native driver of the requested peripheral device to execute, and 
connecting, through the native driver, the computer to the requested peripheral device," as 
recited in claim 12. 

For the foregoing reasons, withdrawal of the rejection of claim 12 is respectfully 
requested. Dependent claim 13 refers to claim 12, and therefore patentably distinguishes over 
the cited art. 

Further, dependent claims 6, 10 and 12 refer to independent claim 1, and therefore 
patentably distinguish over the cited art. 
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NEW CLAIM 

New dependent claim 21 recites, in part: "wherein the generic routines include a routine 
to send data to the peripheral device and to collect data from the peripheral device." Support 
for the new claim can be found, for example, in Fig. 5 and the related discussion in the 
application specification. 

CONCLUSION 

For all the above reasons, the applicants respectfully submit that this application is in 
condition for allowance. A Notice of Allowance is earnestly solicited. 

The Examiner is invited to contact the undersigned at (202) 220-4200 to discuss any 
matter concerning this application. 

The Office is authorized to charge any underpayment or credit any overpayment to 
Kenyon & Kenyon LLP's Deposit Account No. 11-0600. 

Respectfully submitted, 

KENYON & KENYON LLP 

Date: April 17, 2009 /Matthew H. Poison/ 

Matthew H. Poison 
(Registration No. 58,841) 

Kenyon & Kenyon LLP 
1500 K Street, NW 
Washington, DC 2005-1257 
Telephone: (202) 220-4200 
Facsimile: (202) 220-4201 
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